The present invention relates generally to computing and software development, and particularly to an automated system and method for managing software testing.
During the course of developing a software program, one drawback associated with large software development projects relates to the tendency of software developers and testers to work in isolation on the various and sundry software components. As a result, these personnel have been known to develop a variety of test artifacts without leveraging the testing efforts of other development personnel.
In order to address the aforementioned drawback, various collaborative software development tools have been introduced. These development tools may include, e.g., requirements management, quality management, source control management tools, etc.
In some cases, the software development tools are based on the client-server model, with a software development manager program residing on a server. This program was configured to manage access and publication of the software components, test cases, and the test programs used to test the components in accordance with its particular test case(s). The server also typically included a shared repository for storing the components, test cases, and the test programs. Of course, the aforementioned entities may have been developed by multiple developers and testers using a client developer system. The client: systems could include any suitable development device (or system) known by those of ordinary skill in the art, such as other server computing systems, desktop computers, workstations, mainframes, hand held computing devices, or telephony devices, etc. To fully appreciate the magnitude of a large scale software development process, it may be helpful to provide an overview of the process flow performed by multiple software developers and testers in a distributed software development environment.
In the beginning of any project, the system architects provide a high level design that specifies, for example, high level system operations, user interfaces (e.g., graphical user interface (GUIs), etc.), messaging, etc. Based on the high level design, the developers specify components (e.g., functions, subroutines, etc.), algorithms, and etc. that implement the operations. While performing these tasks, the software testers may be developing (or at least planning for) the test cases that will be used to test the individual components and the component interfaces.
A component test case is often directed toward the various scenarios under which that component may be executed; for example, the component may be executed by a variety of software programs, in different system settings or configurations, or with a variety of file system attributes, etc. A test case may also specify test component operations under error conditions (such as various invalid settings), to validate the messaging operations of the components. The test cases may further consider interactions of the components with client level, server level and other third party software. The test cases may test the user interface operations.
As alluded to above, the software development process may be carried out with a multiplicity of developers, testers, and managers. As a result, test case documentation and management during all the various phases of the software development process becomes problematic, to say the least. Thus, when the project management team decides to change the software requirements—or add new requirements—all of the test case documentation must be updated to reflect the new requirements. Because this is currently a task that is performed manually, software test teams spend a large amount of time doing requirement analysis tasks and the corresponding test case updates.
To be specific, the task of understanding the impact of a requirement change on all of the various test cases currently requires painstaking human cognitive input. When managing a large software development project, i.e., one that includes a large list of software requirements, the problem of managing the related test cases becomes extremely complex and thus very difficult. One issue relates to the testers themselves; simply stated, different testers have different perspectives and may evaluate the impact of a requirement change quite differently. Thus, testing results may be uneven.
The aforementioned problems are further exacerbated by the tendency of software development teams to use iterative methodologies (e.g., Agile). Because an iterative approach is employed by design, changes to the requirements necessarily occur quite frequently. As a result, the test cases must be frequently updated as well. Moreover, requirement changes may also impact other project assets such as architecture and design documents. Accordingly, these documents must also be updated.
What is needed therefore is a system and method for automatically managing (updating) project assets (e.g., test cases, architecture, designs, etc.) in response to changed or new requirements.